1. Field of the Invention
The invention relates generally to web application development systems. More specifically, the invention relates to a mechanism for monitoring data flow in a web application, particularly during testing and debugging of the web application.
2. Background Art
A web application is a web site where users can access the information they need and change the state of application logic on a server through a set of web pages. Development of web applications is usually centered around tools and technologies. A web application centered around the Java™ technology may include the following: JSP™ pages and Java™ servlets that handle HTTP requests and generate dynamic content, server-side beans that encapsulate application behavior and state, static HTML files, DHTML files, image files, sound files, and libraries with additional Java™ components, such as client-side Java™ applets and any Java™ class files used by the other Java™ components. The J2EE™ specification describes a standard for how to organize such files into web modules, including describing how they are accessed. The web modules could be developed in an IDE, such as sold under the trade name Forte™ for Java™ by Sun Microsystems, Inc., Palo Alto, Calif.
The process of test-running and debugging web applications that provide dynamic responses to different user inputs involves testing each component that generates pages with every possible type of user input. This includes user input that is technically incorrect (e.g., entering “&&^%” into a field where the expected input is a U.S. zip code). To understand how the process works, consider an e-commerce application that contains a set of pages (A–G) that allows a user to move through a checkout process. The sequence of events for the checkout process is outlined in Table 1 below. A common architecture for this type of web application would be to have each of the pages (A–G) correspond to an individual JSP™ page. Further, because the order in which the pages can be traversed needs to be controlled, all requests for these JSPs™ are handled by a servlet, which allows them to be displayed in appropriate circumstances.
TABLE 1Sequence of events for checkout processPageEventAThe user views the contents of the shopping cart for thepurposes of accepting the selected items. Page A is displayed onlyif the user has selected some items.BThe user enters their credit card information and home address.CThe information from page B is displayed, giving the userthe option to go back to page B to correct the information ormove forward to page D.DThe user enters the shipping address.EThe shipping address from page D is displayed, giving the user theoption to go back to page D to correct the shipping addressor move forward to page F.FAll the information entered by the user (i.e., items purchased,credit card information, home address, and shipping address)is displayed. Page F gives the user the option to proceedwith or cancel the transaction.GA thank-you note is displayed if the user completes the transaction.
Now, suppose that the developer has identified a problem with how the input from page D (i.e., the shipping address) is processed. In order to reproduce the problem, the developer has to achieve a certain state with respect to the web application. This would involve first performing the HTTP transactions required to put something in the shopping cart, or else the controller servlet will not allow the pages to be accessed at all. Then the developer has to move through page A, fill in credit card information and home address on page B, move through page C, and fill in shipping address on D in order to reproduce the problem. HTML forms need to be filled in order to allow the resource that needs debugging to be accessed.
In the scenario described above, it is clearly desirable for the developer to be able to place the web application in the desired state without having to enter data through HTML forms in order to put something in the shopping cart and reenter the same data into the different pages. The mechanism described in U.S. patent application Ser. No. 09/789,238, supra, allows a user to collect information about HTTP transactions and replay the HTTP transactions at a later time. If the HTTP transactions during shopping (i.e., while selecting items) and the checkout process are recorded, they can be replayed at a later time. To use this mechanism for debugging the web application described above, the developer would have to find the desired transactions to replay, and then replay each one individually. This process has to be repeated for each debugging cycle.